Fixing groups - best practice recommendations?

Our Doors environment has been through several phases of 'oh, let's do things this way' so it's a bit of a mess.  The specific issue I'm looking at now relates to users and group management.  We've agreed on a limited number of Doors groups that map to organizational functional groups; that part is all good.  We'd like to clean up about a zillion one-off groups but don't want to just delete them in case they're buried in hard to see placs and would break things if we just yanked them.

I found DXL that let's me get the list of all groups for each user and will use that as the basis for moving users into new groups.

Do you have recommendations for how to kill off the old groups with the least amount of effort and pain?

Thanks for any ideas.

Doug

I'm new at this and am currently off searching for ideas.  I'm happy to do the research so feel free to offer up search terms that will help get me to the reasonable answers.


TD66_d_f - Mon Dec 16 12:14:12 EST 2013

Re: Fixing groups - best practice recommendations?
llandale - Mon Dec 16 14:45:19 EST 2013

I insist the Project Access group names start with the name of the Project.  There would thus be groups "ProjA_ReqManagers" and "ProjB_ReqManagers"; I had not considered a database wide "ReqManagers" group; but perhaps I should.  Project Admins must control their projects by knowing everybody who should have access and adjusting their several group's memberships.

As for old Groups: You need to plow through "everything" and list all the specific accesses.

  • for every folder
  • for every module
  • Opem every module
  • for every object
  • for every attr Type
  • for every Addr Def Def
  • for every attr Def Value
  • for every view
  • for every link
  • for every whatever I've forgotten
  • If the thing has "Specific" accesses then report all the access records.
  • for objects; find some clever abbrevuation since a module may have 1000 objects with specific permission.  For example, don't list accesses that are duplicates of the Module.

Sort the huge report on the "User" name column, ad you get to see exactly what that group/user has access to.

-Louie

Oh joy!
TD66_d_f - Mon Dec 16 15:13:33 EST 2013

llandale - Mon Dec 16 14:45:19 EST 2013

I insist the Project Access group names start with the name of the Project.  There would thus be groups "ProjA_ReqManagers" and "ProjB_ReqManagers"; I had not considered a database wide "ReqManagers" group; but perhaps I should.  Project Admins must control their projects by knowing everybody who should have access and adjusting their several group's memberships.

As for old Groups: You need to plow through "everything" and list all the specific accesses.

  • for every folder
  • for every module
  • Opem every module
  • for every object
  • for every attr Type
  • for every Addr Def Def
  • for every attr Def Value
  • for every view
  • for every link
  • for every whatever I've forgotten
  • If the thing has "Specific" accesses then report all the access records.
  • for objects; find some clever abbrevuation since a module may have 1000 objects with specific permission.  For example, don't list accesses that are duplicates of the Module.

Sort the huge report on the "User" name column, ad you get to see exactly what that group/user has access to.

-Louie

I kind of thought it was going to turn into a giant recursive search and report thing.  Fine grain control has a cost and I think this is it...

Maybe I go old school IT...delete <whatever>...wait...see who yells...fix <what's borked>...

As it happens, we're relatively small and engineers work on numerous projects.  Generally, there's not a need to create terribly restricted groups based on projects so single functional groups works OK for us. 

I guess this is as good a way as any to learn DXL...what could possibly go wrong? ;-)

Thanks you so very much for your prompt reply.

Doug

 

Re: Oh joy!
EHcnck - Thu Dec 19 17:09:29 EST 2013

TD66_d_f - Mon Dec 16 15:13:33 EST 2013

I kind of thought it was going to turn into a giant recursive search and report thing.  Fine grain control has a cost and I think this is it...

Maybe I go old school IT...delete <whatever>...wait...see who yells...fix <what's borked>...

As it happens, we're relatively small and engineers work on numerous projects.  Generally, there's not a need to create terribly restricted groups based on projects so single functional groups works OK for us. 

I guess this is as good a way as any to learn DXL...what could possibly go wrong? ;-)

Thanks you so very much for your prompt reply.

Doug

 

couldn't you just set everything to inherit strip access that applys then add the new groups and permissions?

Re: Oh joy!
TD66_d_f - Thu Dec 19 18:59:19 EST 2013

EHcnck - Thu Dec 19 17:09:29 EST 2013

couldn't you just set everything to inherit strip access that applys then add the new groups and permissions?

Side note: I am really new at this so I'm only beginning to learn what you can and can't do via script.

So that sounds like a great idea.  I'll see if I can figure out what I actually need to do and then look for the least complex solution.  Right now, I'm running scripts to try and figure out how complex the users, groups, and permissions are.

Thanks for the idea!

Doug